Macworld Expo - Developer Central & Net Innovations

home *** CD-ROM | disk | FTP | other *** search

/ Macworld Expo - Develope…Central & Net Innovations / Developer Central and Net Innovators (MacWorld Expo) (January 1999).iso / Developer Central / Metrowerks CodeWarrior / CodeWarrior Pro 4 Release Notes / PowerPlant Notes / Debugging Classes Release Notes < prev next >

Wrap

Text File | 1998-08-21 | 24.8 KB | 638 lines | [TEXT/CWIE]

======================================================================== Metrowerks PowerPlant Debugging Classes Release Notes ======================================================================== Version: 1.1, Part of PowerPlant 1.9.2, CW Pro 4 Date: 21 August 1998 Author: John C. Daub ======================================================================== The PowerPlant Debugging Classes are a set of utilities to aid in the development of PowerPlant-based projects. They provide means and mechanisms to validate, stress, gain and record information all towards the end of helping you to write more solid and less buggy code. They build upon existing PowerPlant mechanisms and extend them to include 3rd party support as well as original ideas. ======================================================================== New Features in This Version ======================================================================== Added in v1.1b2 (28 July 1998) * IMPORTANT NOTE: Due to a bug in the MSL (MW07208), you will need to use at least MSL 2.4.6 to utilize this version of the debugging classes. See the "Known Problems" section of this note for more details. * Updated all code to work with UDebugging changes (UDebugging is now a namespace instead of a class, so various code needed updating). - UDebuggingPlus Updated declarations of gDebugThrow and gDebugSignal - PP_Debug.h Updated all macros to conform to new techniques utilized in UDebugging.h for namespaces. - PP_DebugConstants.h Obsoleted the following constants: cmd_gDebugThrowLowLevel cmd_gDebugThrowSource cmd_gDebugSignalLowLevel cmd_gDebugSignalSource Created cmd_gDebugThrowDebugger, cmd_gDebugSignalDebugger which utilize the same CommandT as the "low level" versions. - LDebugStream Since there is no further distinction between low and source level debuggers, the EFlushLocation has a new flushLocation_Debugger. The old enums remain for compatibility, but are obsolete. Flush() updated to utilize new enums and locations. - LDebugMenuAttachment.cp Updated to use the new debugAction_Debugger enum. The old low-level and source debugger enums have been removed. Updated the menu items and handler functionality to reflect the new UDebugging enums. - UOnyx Updated AlertThrowAt to match UDebugging's version Updated macros to conform to PP namespace. * Updated demo to match UDebugging changes as well as support for the PowerPlant namespace. Added in v1.1b1 (15 July 1998) * Rewrote UProcess a bit. SProcessInfo is more than a simple struct now. It allocates and hides the storage for the name and FSSpec and uses a ProcessInfoRec for the rest. This avoids copying in UProcess::GetInfo(). If you wish to access the information directly, the ProcessInfoRec is declared public: SProcessInfo myInfo; UProcess::GetMyInfo(myInfo); FSSpec fileSpec = myInfo.info.processAppSpec; Accessors for spec and name have been provided. Additional cleanups were done to GetCurrentPSN(), GetMyPSN(), and then how this would have affected the rest of UProcess. Added in v1.1a5 (20 May 1998) * Renamed the "MoreFiles 1.4.8" folder to simply "MoreFiles". It's more generic, eases pain up upgrades and setting paths. The MoreFiles' Readme should always be included and should contain version info. Added in v1.1a4 (7 May 1998) * Updated to version 1.0b19e10 of the Spotlight API * Added menu access to the DebugNew flags (see the DebugNew docs for usage information). Added in v1.1a3 (24 April 1998) * None. Getting the bugs squashed. Added in v1.1a2 (22 April 1998) * None. Concentrating on bug fixes. Added in v1.1a1 (21 April 1998) * None. Concentrating on fixing bugs (I mean, what good are buggy debugging classes ;-) ======================================================================== Bugs Fixed in This Version ======================================================================== Fixed in v1.1a5 (28 May 1998) * Modified how UMemoryEater and LTreeWindow choose to create the window. Previously they tried to build from 'PPob', but if the resource wasn't around, then they built on the fly. This is still the procedure, but instead of throwing an exception if the resource isn't present (and then some annoying breaks into the debugger if "Break on C++ Exception" is enabled) now we check for the resource by a simple "if != nil" check. If it's nil, build on the fly. Simple, a bit cleaner, and certainly less annoying :-) Fixed in v1.1a4 (11 May 1998) * LDebugMenuAttachment::FindUniqueMenuID() could hit infinite recursion if looking for a submenu of ID 1 (as inStartID) and there was a 'MENU' resource of ID 1. The checks to (en)force the submenu ID limits have been removed and replaced by a simple sanity checking Assert_(). This fixed bug MW07042. Fixed in v1.1a3 (24 April 1998) * The tree classes (LCommanderTree, LPaneTree) were plagued by problems of nasty flicker and scrolling/drawing problems. I cleaned this up by using a text engine instead of just blitting to screen. Now I put all the text into a Handle, construct a StScrpHandle to make it look pretty, and life is good. The implementation is a wee funky, but I wanted to ensure some sort of backwards compatability, but also a way to expand (e.g. you could use CWASTEEdit instead of LTextEditView if you wanted to with a little subclassing and overriding). If you have an existing project, you will need to add LTextEditView.cp and UTEViewTextAction.cp to your project. One "big" change was that I needed to move to a monospaced font for the display. Since spaces are used to indent now, things just didn't look good with a variable-width font, but of course you are welcome to use that if you wish. All in all, everything will look pretty much the same to the end user, just changed the innards, but it performs a lot better. Fixed bug MW06324. Fixed in v1.1a2 (22 April 1998) * When QC changes state, if the state change was not performed through the LDebugMenuAttachment menu (e.g. activate QC via its hotkey), the menu was not updated to reflect the state change. This is a combination of how PowerPlant defers menu updates until absolutely needed and that QC doesn't "broadcast" state changes. Due to these factors, LDebugMenuAttachment (only when PP_QC_SUPPORT is true) is also an LPeriodical whose SpendTime will poll for the QC state and keep the menus updated accordingly. Adds a slight bit of overhead, but now state feedback is properly conveyed. * The SuppressThrow_()/ChangeThrow_() and SuppressSignal_()/ ChangeSignal_() macros declared the same variable names. This prevented them from being used at the same time (the joys of copy and paste!). Changed the Signal_() macros to use a more appropriate and unique term (signal!) * UVolume The volume iteration mechanisms had problems with strange volumes, like audio CD's. This was noticed when LDebugMenuAttachment did its searches for ZoneRanger. This has been fixed as best as it really can be, but after discussions with Apple DTS on the subject, there are still obscure situations that could still cause problems. This addresses bug MW06289. * As a consequence of the above bug fix (MW06289), the searching mechanisms in LDebugMenuAttachment for ZoneRanger have been improved slightly. Now there are some additional checks if previous checks fail, and instead of searching every time we launch, we cache an AliasHandle to ZoneRanger. (As an interesting bit of information about the above 2 bugs, I've included my coorespondance with Apple DTS on the subject at the end of these release notes, just if you're curious.) Fixed in v1.1a1 (21 April 1998) * UProcess::GetCurrent() removed. It was an exact duplicate of the UProcess::GetCurrentPSN() method (oops!). Just update your code to call GetCurrentPSN instead. * UProcess::GetMyPSN() The original (v1.0, PP v1.9) implementation of this routine was problematic and actually unnecessary (made things more complicated than they had to be). I've been assured by Quinn "The Eskimo!" at Apple DTS that the toolbox routine ::GetCurrentProcess(), if called at system task time, will always return the PSN of the active process (if you're calling this routine, you should be the active process, therefore GetMyPSN() should always be logically correct). However, if you call ::GetCurrentProcess() at interrupt time, you should be prepared to handle it returning kNoProcess (or an error) to indicate as such. Therefore the methods in UProcess probably aren't the most interrupt safe (as they can throw exceptions anyways). Also, some UProcess methods required a 'BNDL' resource to be present (this was due to the subsequent calling of GetMyPSN). This is no longer a necessary requirement. This fixed bug MW06178. * UProcess::AmICurrent() Removed this routine as it was unnecessary after the above change to GetMyPSN (it compared the results of GetCurrent() with GetMyPSN() so you can see why this is no longer necessary). If you can call the routine, 99.99% you are the current process. * UProcess::GetPreviousPSN() Call AddItem instead of InsertItemsAt as it's faster and the same behavior in the end. * Tried to restructure and guard uses of third party supports (QC, Spotlight, DebugNew, etc.) a lot better so you didn't necessarily have to use them or have their files pulled in unnecessarily. This fixed bugs MW06223, MW06324. * Cleaned up the demo application's "Validate PPob" dialog to be a little more descriptive about just what the dialog is asking for. This fixed bug MW06678. * Trees. If a modal window is frontmost, one can no longer open the commander and/or pane tree windows. Previously if there was a modal dialog, the menu would be enabled, yet the window would appear and then disappear immediately. This is because the command to show/hide the window is the same (it's a toggle). And since the debug menu is an attachment, when the command was generated from the menu, the command is handled by ExecuteAttachments and then again by the subsequent ObeyCommand! So to prevent this, the menu item is disabled. You can still however manipulate the tree refresh time from within a modal dialog. This fixed bug MW06678. ======================================================================== Known Bugs and Incompatibilities ======================================================================== Present in any version (29 July 1998) * There is a bug in Pro 3's MSL with the offsetof macro (it was not properly set up for the std namespace and the MSL's ability to toggle on and off). If you receive compile errors in MoreFiles (or anywhere) about size_t being an undefined identifier, chances are it is due to this bug (MW07208). The MSL team has fixed this and it should be in the netborne patch of MSL v2.4.6. Any version of MSL v2.4.6 or greater should function properly in this regard. Present in v1.0 (20 February 1998) * There has been one report that the QC Tests menu displays garbage. I am unable to reproduce this, but if anyone else sees it, please do report it to Metrowerks Technical Support. ======================================================================== Additional Notes ======================================================================== * Please read the "Debugging Classes Documentation" for an overview and usage instructions. * Make sure that you create/allocate the LDebugMenuAttachment on the heap (via operator new) and also explictly delete it. And you should do this in your application object's constructor and destructor. This is what the demo application does and you should model after it. Why? The commander and pane tree windows utilize the application object as their supercommander. If you do not delete the menu before the application object, when the application object is deleted, it will walk the commander chain and destroy items....one of them being the tree windows. But then, the menu doesn't know about this and will go in itself and delete the windows... double delete and bad crash! HOWEVER! This bug should NOT be a problem any longer... due to the introduction of LTreeWindow (and integrating it throughout the debugging classes). But I still wish to mention this problem as someone perhaps utilizing their own menu/window scheme could still potentially run into this problem. * UDebugUtils::GetLowLevelDebuggerInfo() has problems with Norton CrashGuard. There is a bug (confirmed with Symantec) with CG that basically "trashes" the debugWorld.. or rather, CG does something to the debugWorld that we can't very well deal with. v2 (and later) of CrashGuard is supposed to fix this, install a proper sigature, and give a means for accessing old MacJmp and MacJmpFlag. But any version of CG less than 2 (1 or zero) will remain a problem. Have it be known that if you have CrashGuard installed, any calls to this method (directly or indirectly) will return unknown values. Workaround? Remove CrashGuard (I suggest this because I personally find MacsBug a more useful development tool). Do not just turn it off, but totally remove it from your Extensions folder. It seems that if it is just off, it still loads and trounces memory... it just won't catch your problems. You must remove it entirely (via the Extensions Manager or some similar such mechanism). I am working to find the details and a real solution to the matter. * Some bugs have been found in various support products (e.g. MacsBug 6.5.3a3c1's heap scrambling is broken, known Apple bug; QC API has some glitches in it; QC save/restore state doesn't seem to work; bizarre Spotlight error writing out a large debug output; MW Debug can't handle long DebugStr's). All bugs I have discovered I have reported to the proper people, and all bugs are, AFAIK, being looked into. ** Note: MacsBug 6.5.4a4 (shipped on CW Pro 3) does fix the heap scrambling problem. If you find a bug with a non-Metrowerks product but with/through the use of these classes, please CC Metrowerks Support on your correspondance with the other company(s). * The #define new NEW trick is documented to have problems (it's a hack). The purpose of this trick is for DebugNew. In DEBUG_NEW_LEAKS mode, a leaks.log is generated. To try to make the log output useful, DebugNew uses a custom operator new that takes __FILE__ and __LINE__ as arguments (see DebugNew.cp/.h for more information). Again, this is only of use under DEBUG_NEW_LEAKS. In an effort to reduce the pain of modifying code (especially code that is not yours) to use "NEW" instead of "new" (to get the gain from DebugNew), a "#define new NEW" trick is used. Typically this can work, but as I mentioned, it's a hack and has problems. Since this happens through the magic (evil?) if the preprocessor, any instance of "new" will be replaced by "NEW" and subsequently DebugNew's tricks. This means the most pain for any declarations and definitions of operator new (such as done in LThread, and LReentrantMemoryPool/LRMPObject). The compiler will choke. Some workarounds include: - Not using DebugNew at all (ensure DebugNew.cp is not in your project and PP_DEBUGNEW_SUPPORT is #defined to zero). - Manually editing the code you wish to leak check to explicitly use "NEW" instead of "new". - Using DebugNew with #define DEBUG_NEW DEBUG_NEW_BASIC. This way you will gain all benefits but leak checking. You can pick that back up through something such as Spotlight. We welcome your comments, criticisms, feedback, suggestions, bug reports, etc., and encourge you to please let us know about your experiences with these classes. There are a great many combinations and possibilities of how they can be used, and I very well might have missed something. :-) ======================================================================== Contacting Metrowerks ======================================================================== For bug reports, technical questions, and suggestions, please use the forms in the Release Notes folder on the CD, and send them to support@metrowerks.com See the CodeWarrior on the Nets document in the Release Notes folder for more contact information, including a list of Internet newsgroups, online services, and patch and update sites. ======================================================================== Metrowerks Corporation ---- For those curious, some interesting notes from Apple Developer Technical Support on the subject of volume iteration --- Due to bug MW06289 (where UVolume iterated over an audio CD and caused UVolume::FindAppOnVolume()'s call to ::PBDTGetAPPLSync() to return a paramErr), I asked Apple Developer Technical Support (DTS) what other sorts of volumes I need to watch out for when taking this approach (e.g. ISO 9660 or some other non-HFS volume). Pete Gontier responded with the below (with credits to Jim Luther, oh File Manager god). I figured to pass it along as it might be at least something interesting. RESPONSE --------------------------------------------------------- John, Nice to hear from you again. Congrats on shipping CW Pro3! To answer your specific question, the unfortunate truth is that various file systems will produce various error behaviors with the desktop database routines, as you have found. The last time I wrote code that needed to handle such things as audio CDs, I just special-cased some of the errors and commented them in the code as to why I was treating them specially. That's the only technique I know of for dealing with this problem. Your code is not at fault, and there is no way to ask a volume "Do you REALLY support a desktop database or do you just CLAIM to?" :-( And now here's some general background info: >From time to time, people need to know how to launch an application given a document or a creator code. It sounds like you are trying to do something similar. Let me know if I'm way off in my reading between your lines. There are a number of ways to achieve this effect. I list them here in decreasing order of desirability. --- 1 --- You can ask Finder to do it for you with an AppleScript (or the equivalent AppleEvents) like this: tell application "Finder" set appToLaunch to (application file id "ttxt") as alias end tell ...where "ttxt" is the creator code of the application you care about. This is the highest level way to do this. Your app can feed this script to OSACompile and OSAExecute or figure out how to construct the relevant AppleEvents. There are some useful MacsBug commands in the AppleScript SDK: Dev.CD Jul 97 SDK1 Development Kits (Disc 1) AppleScript Development Tools Tools Goodies Macsbug Resources --- 2 --- You can use a complex algorithm we've provided to some developers. It takes a long time to implement; I know because I was the first developer to receive a description of the algorithm and I implemented it. I'll include a discussion of this algorthm at the end of this message. This description was valid as of Finder 7; I'm not sure how it relates to Finder 8. Using the AppleEvents approach documented above in --- 1 --- isolates you from this kind of change. --- 3 --- You can use PBDTGetAPPL. This call searches the desktop database of a given volume for an application with a given creator code that was last copied onto the volume. This call is documented on page 9-15 of Inside Macintosh: More Macintosh Toolbox and on the web along the following URL: <http://devworld.apple.com/dev/techsupport/insidemac/ MoreToolbox/MoreToolbox-497.html> Also, don't miss Q&A TB 19. <http://devworld.apple.com/dev/qa/tb/tb19.html> --- 4 --- Finally, you can use PBCatSearch. This call lets you search the entire catalog of a volume and filter with various criteria including creator and file type. This call is documented starting on pages 2-38 and 2-204 of Inside Macintosh: Files and on the web along the following URL: <http://devworld.apple.com/dev/techsupport/insidemac/ Files/Files-252.html> Also, don't miss Technote FL 31: <http://devworld.apple.com/dev/technotes/fl/fl_31.html> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- You may need to mix and match from among the above numbered techniques. And, as usual, the MoreFiles library should be a great help with respect to sample code and/or library code you can simply call. MoreFiles is available on the Tool Chest Edition of the Developer CD Series: Dev.CD Aug 97 TC Sample Code Files MoreFiles 1.4.6 (Editors Note: as of this writing it is also available at: <ftp://members.aol.com/JumpLong/> and is also included as part of the debugging classes -JCD) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- How Does Finder Determine Which Application to Launch (assuming multiple volumes are mounted)? Since there could be more than one copy of the application, there is some logic behind which copy of an application gets used when you open a file. Here's what the Finder currently does (we found this from walking through the Finder source code by hand - we cannot guarantee this behavior in the future). Start with 1 and when you find a condition that works, stop. 1) If an application with the correct creator is already running, it is used. (You can use the Process Manager to look through the list of running processes to check for this.) 2) If the volume the file is on is a local volume (vMServerAdr returned by PBHGetVolParms is zero) and an application with the correct creator is found on that volume (by searching the volume's desktop file or desktop database), then the copy of the application which was installed last is launched. (See the PBDTGetAPPL routine in Inside Macintosh:More Macintosh Toolbox for more info on the Desktop Manager. See Tech Note TB 6 - Resources Contained in the Desktop File for Desktop File information. The Finder tries the most recent first and if it cannot be found, tries the other matches returned by calling PBDTGetAPPL with an index.) 3) If an application with the correct creator is found on the boot volume, then the copy of the application which was installed last is launched. (Again, the Finder uses PBDTGetAPPL for this) 4) If an application with the correct creator is found on the non-local volume the file is on, then the copy of the application which was installed last is launched. 5) Each volume (except for the boot volume and the volume the file is on) in the Finder's list of volumes is checked for a copy of the application. If an application with the correct creator is found, then the copy of the application which was installed last is launched. (How is the list of volumes ordered? I'll get to that in a second...) 6) Each open window is searched for an application with the correct creator. The windows are searched by volume in the order that the volumes are in the list. If one is found, then it's launched. This catches those times where an application isn't in the desktop database. (To do this, you'd have to use ask the scriptable Finder for a list of open windows.) Volumes are inserted into the Finder's volume list when they are mounted. They are inserted in the list based on a three part key: 1) is the volume local (vMServerAdr returned by PBHGetVolParms is zero), 2) does the volume support CatSearch (bHasCatSearch bit in vMAttrib returned by PBHGetVolParms is set) 3) volume speed (vMVolumeGrade returned by PBHGetVolParms; lower values are better; 0 = unrated). So, if you have two non-local volumes and only one supports CatSearch, the one with CatSearch will be used first. If both support CatSearch, the one that's fastest will be used. Because the Finder caches information, the Desktop database may not have the information about the most recently version of Netscape. Situations that would not allow the Finder to see the most recent version of Netscape include: -- if you copy an application onto a volume with a program other than the Finder, the Finder won't add the new application to the desktop database until it sees it the first time. -- if you copy an old version of an application to your hard disk, it may become the version that is launched (since the Finder will launch the most recently "installed" version it sees, not necessarily the most recent version). In this situation, you would want to use PBGetCatInfo to compare creation dates. -- Pete Gontier, Integer Poet Apple Macintosh Developer Technical Support Copyright 1998, Apple Computer, Inc.